feat(editor): merge the background facet into video effects - #451

Background and Effects were two inspector facets, and four of Effects' five
controls were background controls in disguise: the blur blurs the background,
the shadow falls on it, and roundness and padding exist only to let it show
through. A user who wanted no background opened "Background", found nothing but
wallpapers, and filed #84 — the split hid the answer in the tab that doesn't say
"background".

The facet is gone. VideoEffectsPane now carries three sections: Background
(picker + blur), Frame (shadow, roundness, padding) and Motion (motion blur).
Motion blur is alone in its section and correctly so — it blurs the recording as
it moves, never the background, so it belongs under neither of the other two.

The picker itself floats behind a swatch trigger rather than sitting inline. Its
18-swatch grid was ~300px on its own and pushed the frame sliders below the fold
on a laptop window, which would have reproduced #84's failure one level down.
Collapsed, the whole pane is 462px instead of 806px and fits with no scroll at
1512x982; Frame moves from 502px to 158px. Same trade the aspect-ratio menu in
the timeline toolbar already makes: big choice, small trigger.

Two keys added across all 13 locales (effects.frame, effects.motion); the pane's
help text joins the two existing sentences rather than adding a 14th string to
translate.

Refs #84
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…ettings

#84 asks for a way to turn the background off. The honest answer was four
settings in three places — padding, roundness and shadow to zero, plus an
aspect ratio matching the footage — which is why nobody found it. Merging the
facets put all four in one pane; this puts them behind one switch.

It is DERIVED, not stored. "No background" is a shape those four settings are
in, not a fifth setting alongside them, so `fillsFrame()` reads it back instead
of persisting a flag that could disagree with them: nudge any slider and the
switch turns itself off, with no schema change and nothing to migrate.

The aspect ratio is part of the test rather than an afterthought. Padding 0 only
fills the WIDTH — a 16:10 capture in a 16:9 project keeps its wallpaper bars at
zero padding, which is exactly why the issue reads as unfixable to someone who
already found the slider. The target shape comes from collectNativeFormats(),
the same source the ratio picker's ORIGINAL section reads, already sorted by
clip count then pixel area, so the two can never disagree.

Switching off restores the shipped defaults rather than a remembered "before":
a hidden slot only one control writes is state that rots, and every value it
restores is one slider away. The ratio is left alone — wanting the background
back is not asking for the output to be reframed.

Toggle gains an optional aria-label; it renders no text of its own, so the
switch had no accessible name.

Refs #84
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

The previous commit told the user that clips in another shape still show the
background, and left it there. Telling someone about a decision made for them is
not the same as letting them make it: the shape was whichever `collectNativeFormats`
sorted first — the majority — so a project that is mostly landscape with two
portrait inserts could never be made to fill on the portrait ones. The
information was honest and the control was still missing.

So when the timeline has more than one shape, the switch grows a chooser: one
chip per distinct shape, each carrying its clip count, active one highlighted.
Picking one writes that aspect ratio. The majority stays the default on
activation — it is the right guess — it is just no longer the only answer. The
counts make the trade visible, which is the same information the ratio menu's
ORIGINAL section already shows, in the place where the decision is now made.

The caveat stays under the chooser, because choosing a shape does not make the
others fill; it decides which ones do.

Tested against a real two-shape document — the case neither the browser harness
(no project) nor the other tests (no timeline) could reach.

Refs #84
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…ame the pane

The aspect ratio lived in the timeline toolbar, among Trim / Speed / Zoom /
Full Camera and the transport. Everything around it was about the timeline, so a
shape selector there read as a viewport control — something that changes what
you are looking at, not what gets exported. That placement was never argued for:
it arrived inside 1f25410, a commit about per-clip crop export and a HUD
redesign, and no decision record mentions it.

It belongs with padding, roundness and shadow, which only mean anything measured
against a known frame. With it here, the answer to #84 is one panel instead of
three places — which is what this PR set out to do and had, until now, only half
done: the one-click action covered the common case while the manual path still
crossed two surfaces.

The timeline's own shapes stay listed under the presets, and deliberately not
only behind "fit a clip": that action also zeroes the frame styling, so without
those rows there would be no way to export at the footage's native shape while
keeping a padded, rounded look.

Nothing replaces it in the toolbar. An indicator there would either be dead
weight or a second way to author the same setting, and the canvas already shows
its own shape.

"Video Effects" stopped being true once a format moved in — an output shape is
not an effect. The pane is Composition. That name was too close to "Layout"
until Layout became "Camera layout", which is what that facet has always
actually been (webcam presets, mask shape, mirroring; it is already disabled
without a webcam). Its preset field re-used the pane title and now uses
layout.preset, which is what the field is.

Refs #84
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

The Format row was rendering twice. I duplicated it while moving the "fit"
action, and the duplicate survived a typecheck because both copies were valid
JSX bound to the same state — so the two menus even opened together. Removed.

"Fit" moves out of the settings list and onto the Frame header. It is not a
fifth control alongside format / shadow / roundness / padding: it overwrites all
of them at once. The nearest thing it has to a peer is a reset button, except it
resets to a TARGET state rather than to the initial one, and that is not
something a row in the list can say. Styled quieter than what it overwrites,
since it is reached on purpose rather than stumbled into.

Label is now just "Fit" — one string instead of two that varied on whether the
menu would open, which was a distinction about the mechanism, not about what the
button does.

The caveat about clips in other shapes is gone. With it goes `fillsFrame`: it
existed to decide whether to show that line, and a predicate nothing reads is
dead weight. `fitClipPatch` keeps the part that matters — that the aspect ratio
is in the patch at all, because padding 0 only fills the WIDTH.

The Format menu keeps its ORIGINAL section, and keeps it laid out exactly as it
was in the toolbar: token leading, pixel size on the right, clip count appended
only when the timeline is mixed. A row there names an output FORMAT, so the
ratio is its identity — unlike the "fit" menu, where a row names a clip and the
resolution leads.

Refs #84
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…t label

Two findings from review on #451.

The fit tests checked labels and whether a menu opened. Neither clicked a menu
row nor looked at the document, so a regression in `applyFitClip` passed them.
They now read the four frame settings back off the store, including one case
that picks the MINORITY shape — if the menu did not drive the write, the default
would win and the assertion would not notice.

Writing that exposed the same fault one level down: the fixture already carried
`padding: 0, borderRadius: 0, aspectRatio: "16:9"`, so asserting the fitted state
proved nothing — it was the starting state. It now opens on the shipped defaults
at 1:1, which is what a real project looks like before the button is pressed.
Checked by mutation: stubbing `applyFitClip` fails exactly the two new cases and
leaves the other three green, which is also a fair verdict on what those three
were covering.

`getAspectRatioLabel` hardcodes English "Original" for the legacy `"native"`
value, and that value is still reachable — the v5→v6 migration only bakes it into
a concrete token once clip dimensions are known. The group header in the same
menu is localized, so twelve locales showed the two disagreeing.

The third finding (assert the exact defaults restored by the OFF branch) is
obsolete: the action has no inverse any more, and `fillFramePatch` is gone.

Refs #84
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>